                            SUPPORT NOTE S90096
                         THE LICENSE BIT WITH SQL

                                Don Maier
                                 07DEC90

SUMMARY:    Licensing is part of the security mechanism on Tandem
            systems.  In the world of Enscribe, it has one relatively
            simple meaning and function.  NonStop SQL came along and
            added several interleaving meanings.  This paper explains
            these new uses of the license bit.

            The following GUARDIAN 90 operating system utilities must
            be licensed to permit their access to NonStop SQL objects.
            The INSTALL process, when completed normally, performs the
            licensing of these programs.

            $SYSTEM.SYSTEM.SQLCOMP
            $SYSTEM.SYSTEM.SQLUTIL
            $SYSTEM.SYSTEM.SQLCAT
            $SYSTEM.SYSnn.BACKUP
            $SYSTEM.SYSnn.DSAP
            $SYSTEM.SYSnn.FUP
            $SYSTEM.SYSnn.FILCHECK
            $SYSTEM.SYSnn.PUP
            $SYSTEM.SYSnn.RESTORE
            $SYSTEM.SYSnn.SORTPROG

            If the licensing bit is accidentally removed, a number of
            errors can result even when the SUPER.SUPER id uses these
            programs.  The most common error will probably be an error
            49, but other errors can also result.

            This document describes when the disk process, the SQL
            file system, and the SQL Catalog Manager check to see if
            the license bit is set.  Some programs (such as BACKUP and
            RESTORE) need to be licensed for more than one reason.

            The author wishes to thank Lynn Sestak, Michael Stewart,
            and others for helping with the research for this paper.

DETAIL

"Being licensed" is an attribute only of a program file.  Data files
cannot be licensed.  Try it, and you'll get an error 2 (you can't do
this to that).

Only the SUPER.SUPER id (user 255,255) can "license" a program.  This
is normally done with the FUP LICENSE command (and removed with the
FUP REVOKE command.  SUPER's power to LICENSE and REVOKE does not
cross node boundaries.

Sometimes the terms "Enscribe licensing" and "SQL licensing" come up.
Don't be fooled.  While these terms refer to different semantics, all
semantics are built into the "license bit".  As we shall see, this
little bit now sags under the considerable semantic burden it bears.

LICENSING IN THE WORLD OF ENSCRIBE

Things weren't too complicated before SQL.  Licensing had to do with
privileged programs.  A program may be privileged because it has
procedures with privileged (CALLABLE or PRIV) attributes.  A program
may also be privileged because it calls PRIV procedures in a library
directly -- without going through a distrusting CALLABLE interface.

Licensing allows a non-SUPER user id to run a privileged program.  In
this world, SUPER doesn't need licensing.  Programs that other user
id's cannot run without licensing run just fine for SUPER.

While a non-SUPER user id can run a licensed program, it can't debug
it.  Only the SUPER id can.  This is because he who debugs a licensed
program has the keys to the kingdom:  The system lets a licensed
program call any procedure, and to read and modify all data in the
computer.  This power is in the hands of a debugger, who can also
modify the program's behavior by changing its data.

These Enscribe semantics of licensing have been preserved to the
current day.

LICENSING IN THE WORLD OF NONSTOP SQL

NonStop SQL overloaded the notion of licensing with several more
meanings.  All of these new SQL semantics have a common
characteristic:  Not even the SUPER id is immune to the SQL checks for
program licensing.  But SUPER (and only SUPER) can still set and reset
it.

The SQL checks fall into three categories according to whether the
disk process, the SQL file system, or the SQL Catalog Manager
implements the check.

DISK PROCESS CHECKS (Write Security for SQL Catalog Tables)

SQL catalog tables aren't themselves licensed.  But they are special
because they're part of the SQL data dictionary.  A program must be
licensed to write a catalog table.  (It must also pass other security
hurdles defined by the standard GUARDIAN90 RWEP security vector.)

The SQL file system (FS2) includes the setting of a requesting
program's license bit in a message to the disc process (DP2).  DP2
distinguishes catalog tables from user tables.  When it receives a
write request for a catalog table, it determines whether or not the
access should be allowed by examining the setting of the license bit
along with the setting of the 'W' part of the RWEP vector and the
requester's process accessor id.

DISK PROCESS CHECKS (Utility Opens for Read-Write Access)

Normal SQL application programs use "executor" opens of the SQL data
base objects that they access.  SQL utilities often use a different
form of open, a "utility open", which is not subject to the open
invalidation rules of executor opens.

Only a licensed program is allowed to have a utility open for
read-write access.  The disk process returns an error 49 to an
unlicensed program that tries to get one.

If not licensed, RESTORE trips over this error on its first encounter
of an SQL file.  However, this is not the only reason RESTORE needs to
be licensed.

SQL FILE SYSTEM CHECKS (Write Security for SQL File Labels)

The same check used to allow or disallow writes to catalog tables is
used to determine if a requester can alter the file label of an SQL
object.  This makes sense because altering a file label changes the
definition of the object in the label, just as a catalog write changes
the definition of an object in the catalog.

SQL FILE SYSTEM CHECKS (Reading SQL Labels with Stable/Repeatible
                        Access)

Licensing is required to acquire the label lock needed to read a SQL
file label with either stable (test lock) or repeatable access (keep
lock).  Breaking this rule results in an error 1070 ("The process's
programfile is not licensed").

If not licensed, BACKUP trips over this error on its first encounter
with a SQL file.  However, this is not the only reason BACKUP must be
licensed.

SQL FILE SYSTEM CHECKS (Creating and Dropping SQL File Labels)

Creating and dropping SQL file labels is restricted to licensed
requesters.  The restriction is not imposed for temporary labels.

SQL FILE SYSTEM CHECKS (Changing Security of SQL-Sensitive Programs)

The security (owner, security vector, clearonpurge, and progid)
attributes of SQL-sensitive programs are changed with calls to
SETMODEBYCAT.  Only licensed callers succeed.

SQL CATALOG MANAGER CHECKS (Dropping Catalogs)

Normally, a SQL catalog is created and deleted along with a
corresponding entry in the SQL system catalog CATALOGS table.  A SQL
catalog can't be dropped if it doesn't have an entry in the CATALOGS
table  -- unless you are licensed.  This is a case of being licensed
to DROP (in a manner of speaking).

Conversely, a licensed requester can DROP a catalog even if the
attempt to delete its CATALOGS entry fails.

SQL CATALOG MANAGER CHECKS (Re-Securing SQL Catalog Tables)

You can set the security for all the tables in an SQL catalog en masse
with ALTER CATALOG SECURE.  However, most SQL catalog tables cannot be
individually secured with ALTER TABLE SECURE unless you are licensed.
If you aren't, the Catalog Manager returns error 1238 ("you can't do
this to a catalog table").  SQLUtil does a similar check for the
SECURE command.  Just to be different, it returns the warning(!)  9110
("you can't do this to this catalog table").

The PROGRAMS, TRANSIDS, and USAGES tables are exceptions.  Even you
and I non-SUPER types can set the security of these tables without
licensing.

SQL CATALOG MANAGER CHECKS (Non-Standard SQL DDL/Utility Requests)

"Standard" requests are the ones that you can read about in the SQLCI
Manual.  They include the ability to create and drop the SQL system
catalog.

Besides these requests, the SQL Catalog Manager implements a number of
"non-standard" requests for other SQL system processes.  It insists
that its requesters be licensed.  Everything is allowed between
consenting (licensed) programs.

SQL CATALOG MANAGER CHECKS (Catalog Manager Self-Check)

An unlicensed SQL Catalog Manager would be almost useless since it
would be unable to pass the disk process checks for almost any
request.  The SQL Catalog Manager makes an initialization check to see
if it is licensed and shoots itself if it isn't.
